home *** CD-ROM | disk | FTP | other *** search
/ Dictionaries & Language / Dictionaries and Language (Chestnut CD-ROM) (1993).iso / gloss / jargn298 / jargon-v.txt < prev    next >
Encoding:
Text File  |  1991-09-07  |  19.0 KB  |  363 lines

  1. = V =
  2. =====
  3.  
  4. vadding: /vad'ing/ [from VAD, a permutation of ADV (i.e.,
  5.    {ADVENT}), used to avoid a particular {admin}'s continual
  6.    search-and-destroy sweeps for the game] n. A leisure-time activity
  7.    of certain hackers involving the covert exploration of the `secret'
  8.    parts of large buildings --- basements, roofs, freight elevators,
  9.    maintenance crawlways, steam tunnels, and the like.  A few go so
  10.    far as to learn locksmithing in order to synthesize vadding keys.
  11.    The verb is `to vad' (compare {phreaking}).
  12.  
  13.    The most extreme and dangerous form of vadding is `elevator
  14.    rodeo', a.k.a. `elevator surfing', a sport played by wrasslin'
  15.    down a thousand-pound elevator car with a 3-foot piece of
  16.    string, and then exploiting this mastery in various stimulating
  17.    ways (such as elevator hopping, shaft exploration, rat-racing, and
  18.    the ever-popular drop experiments).  Kids, don't try this at home! 
  19.    See also {hobbit} (sense 2).
  20.  
  21. vanilla: [from the default flavor of ice cream in the U.S.] adj.
  22.    Ordinary {flavor}, standard.  When used of food, very often does
  23.    not mean that the food is flavored with vanilla extract!  For
  24.    example, `vanilla wonton soup' means ordinary wonton soup, as
  25.    opposed to hot-and-sour wonton soup.  Applied to hardware and
  26.    software, as in "Vanilla Version 7 UNIX can't run on a
  27.    vanilla 11/34."  Also used to orthogonalize chip nomenclature; for
  28.    instance, a 74V00 means what TI calls a 7400, as distinct from
  29.    a 74LS00, etc.  This word differs from {canonical} in that the
  30.    latter means `default', whereas vanilla simply means `ordinary'.
  31.    For example, when hackers go on a {great-wall}, hot-and-sour
  32.    wonton soup is the {canonical} wonton soup to get (because that
  33.    is what most of them usually order) even though it isn't the
  34.    vanilla wonton soup.
  35.  
  36. vannevar: /van'*-var/ n. A bogus technological prediction or
  37.    a foredoomed engineering concept, esp. one that fails by
  38.    implicitly assuming that technologies develop linearly,
  39.    incrementally, and in isolation from one another when in fact the
  40.    learning curve tends to be highly nonlinear, revolutions are
  41.    common, and competition is the rule.  The prototype was Vannevar
  42.    Bush's prediction of `electronic brains' the size of the Empire
  43.    State Building with a Niagara-Falls-equivalent cooling system for
  44.    their tubes and relays, made at a time when the semiconductor effect had
  45.    already been demonstrated.  Other famous vannevars have included
  46.    magnetic-bubble memory, LISP machines, {videotex}, and a paper from
  47.    the late 1970s that computed a purported ultimate limit on areal
  48.    density for ICs that was in fact less than the routine densities
  49.    of 5 years later.
  50.  
  51. vaporware: /vay'pr-weir/ n. Products announced far in advance of
  52.    any release (which may or may not actually take place).
  53.  
  54. var: /veir/ or /var/ n. Short for `variable'.  Compare {arg},
  55.    {param}.
  56.  
  57. VAX: /vaks/ n. 1. [from Virtual Address eXtension] The most
  58.    successful minicomputer design in industry history, possibly
  59.    excepting its immediate ancestor, the PDP-11.  Between its release
  60.    in 1978 and its eclipse by {killer micro}s after about 1986, the VAX
  61.    was probably the hacker's favorite machine of them all, esp.
  62.    after the 1982 release of 4.2 BSD UNIX (see {BSD}).  Esp.
  63.    noted for its large, assembler-programmer-friendly instruction set
  64.    --- an asset that became a liability after the RISC revolution.
  65.    2. A major brand of vacuum cleaner in Britain.  Cited here because
  66.    its alleged sales pitch, "Nothing sucks like a VAX!" became a
  67.    sort of battle-cry of RISC partisans.  Ironically, the slogan was
  68.    *not* actually used by the Vax vacuum-cleaner people, but was
  69.    actually that of a rival brand called Electrolux (as in "Nothing
  70.    sucks like an...").  It is claimed, however, that DEC actually
  71.    entered a cross-licensing deal with the vacuum-Vax people that
  72.    allowed them to market VAX computers in the U.K. in return for not
  73.    challenging the vacuum cleaner trademark in the U.S.
  74.  
  75. VAXectomy: /vak-sek't*-mee/ [by analogy with `vasectomy'] n. A
  76.    VAX removal.  DEC's Microvaxen, especially, are much slower than
  77.    newer RISC-based workstations such as the SPARC.  Thus, if one knows
  78.    one has a replacement coming, VAX removal can be cause for
  79.    celebration.
  80.  
  81. VAXen: /vak'sn/ [from `oxen', perhaps influenced by `vixen'] n.
  82.    (alt. `vaxen') The plural canonically used among hackers for the
  83.    DEC VAX computers.  "Our installation has four PDP-10s and twenty
  84.    vaxen."  See {boxen}.
  85.  
  86. vaxherd: n. /vaks'herd/ [from `oxherd'] A VAX operator.
  87.  
  88. vaxism: /vak'sizm/ n. A piece of code that exhibits
  89.    {vaxocentrism} in critical areas.  Compare {PC-ism},
  90.    {unixism}.
  91.  
  92. vaxocentrism: /vak`soh-sen'trizm/ [analogy with
  93.    `ethnocentrism'] n. A notional disease said to afflict
  94.    C programmers who persist in coding according to certain assumptions that are 
  95.    valid (esp. under UNIX) on {VAXen} but false elsewhere. Among
  96.    these are:
  97.  
  98.   1.    The assumption that dereferencing a null pointer is safe because it
  99.         is all bits 0, and location 0 is readable and 0.  Problem: this may
  100.         instead cause an illegal-address trap on non-VAXen, and even on
  101.         VAXen under OSes other than BSD UNIX.  Usually this is an implicit
  102.         assumption of sloppy code (forgetting to check the pointer before
  103.         using it), rather than deliberate exploitation of a
  104.         misfeature.)
  105.  
  106.   2.    The assumption that characters are signed.
  107.  
  108.   3.    The assumption that a pointer to any one type can freely be cast
  109.         into a pointer to any other type.  A stronger form of this is the
  110.         assumption that all pointers are the same size and format, which
  111.         means you don't have to worry about getting the types correct in
  112.         calls.  Problem: this fails on word-oriented machines or others with
  113.         multiple pointer formats.
  114.  
  115.   4.    The assumption that the parameters of a routine are stored in
  116.         memory, contiguously, and in strictly ascending or descending order.
  117.         Problem: this fails on many RISC architectures.
  118.  
  119.   5.    The assumption that pointer and integer types are the same size,
  120.         and that pointers can be stuffed into integer variables (and
  121.         vice-versa) and drawn back out without being truncated or mangled.
  122.         Problem: this fails on segmented architectures or word-oriented
  123.         machines with funny pointer formats.
  124.  
  125.   6.    The assumption that a data type of any size may begin at any byte
  126.         address in memory (for example, that you can freely construct and
  127.         dereference a pointer to a word- or greater-sized object at an odd
  128.         char address).  Problem: this fails on many (esp. RISC)
  129.         architectures better optimized for {HLL} execution speed, and
  130.         can cause an illegal address fault or bus error.
  131.  
  132.   7.    The (related) assumption that there is no padding at the end of
  133.         types and that in an array you can thus step right from the last
  134.         byte of a previous component to the first byte of the next one.
  135.         This is not only machine- but compiler-dependent.
  136.  
  137.   8.    The assumption that memory address space is globally flat and that
  138.         the array reference `foo[-1]' is necessarily valid.  Problem:
  139.         this fails at 0, or other places on segment-addressed machines like
  140.         Intel chips (yes, segmentation is universally considered a
  141.         {brain-damaged} way to design machines (see {moby}), but that
  142.         is a separate issue).
  143.  
  144.   9.    The assumption that objects can be arbitrarily large with no
  145.         special considerations.  Problem: this fails on segmented
  146.         architectures and under non-virtual-addressing environments.
  147.  
  148.  10.    The assumption that the stack can be as large as memory.  Problem:
  149.         this fails on segmented architectures or almost anything else without
  150.         virtual addressing and a paged stack.
  151.  
  152.  11.    The assumption that bits and addressable units within an object
  153.         are ordered in the same way and that this order is a constant of
  154.         nature.  Problem: this fails on {big-endian} machines.
  155.  
  156.  12.    The assumption that it is meaningful to compare pointers to
  157.         different objects not located within the same array, or to objects
  158.         of different types.  Problem: the former fails on segmented
  159.         architectures, the latter on word-oriented machines or others with
  160.         multiple pointer formats.
  161.  
  162.  13.    The assumption that an `int' is 32 bits, or (nearly
  163.         equivalently) the assumption that `sizeof(int) ==
  164.         sizeof(long)'.  Problem: this fails on 286-based systems and even
  165.         on 386 and 68000 systems under some compilers.
  166.  
  167.  14.    The assumption that `argv[]' is writable.  Problem: this fails in
  168.         some embedded-systems C environments.
  169.  
  170.    Note that a programmer can validly be accused of vaxocentrism
  171.    even if he or she has never seen a VAX.  Some of these assumptions
  172.    (esp. 2--5) were valid on the PDP-11, the original C machine, and
  173.    became endemic years before the VAX.  The terms `vaxocentricity'
  174.    and `all-the-world's-a-VAX syndrome' have been used synonymously.
  175.  
  176. vdiff: /vee'dif/ v.,n. Visual diff.  The operation of finding
  177.    differences between two files by {eyeball search}.  The term
  178.    `optical diff' has also been reported.  See {diff}.
  179.  
  180. veeblefester: /vee'b*l-fes`tr/ [from the "Born Loser"
  181.    comix via Commodore; prob. originally from `Mad' Magazine's
  182.    `Veeblefeetzer' parodies ca. 1960] n. Any obnoxious person engaged
  183.    in the (alleged) professions of marketing or management.  Antonym of
  184.    {hacker}.  Compare {suit}, {marketroid}.
  185.  
  186. Venus flytrap: [after the insect-eating plant] n. See {firewall
  187.    machine}.
  188.  
  189. verbage: /ver'b*j/ n. A deliberate misspelling and mispronunciation of
  190.    {verbiage} that assimilates it to the word `garbage'.  Compare
  191.    {content-free}.  More pejorative than `verbiage'.
  192.  
  193. verbiage: n. When the context involves a software or hardware
  194.    system, this refers to {{documentation}}.  This term borrows the
  195.    connotations of mainstream `verbiage' to suggest that the
  196.    documentation is of marginal utility and that the motives behind
  197.    its production have little to do with the ostensible subject.
  198.  
  199. Version 7: alt. V7 /vee' se'vn/ n. The 1978 unsupported release of
  200.    {{UNIX}} ancestral to all current commercial versions.  Before
  201.    the release of the POSIX/SVID standards, V7's features were often
  202.    treated as a UNIX portability baseline.  See {BSD}, {USG UNIX},
  203.    {{UNIX}}.  Some old-timers impatient with commercialization and
  204.    kernel bloat still maintain that V7 was the Last True UNIX.
  205.  
  206. vgrep: /vee'grep/ v.,n. Visual grep.  The operation of finding
  207.    patterns in a file optically rather than digitally.  See {grep};
  208.    compare {vdiff}.
  209.  
  210. vi: /V-I/, *not* /vi:/ and *never* /siks/ [from
  211.    `Visual Interface'] n. A screen editor crufted together by Bill Joy
  212.    for an early {BSD} version.  Became the de facto standard UNIX
  213.    editor and a nearly undisputed hacker favorite until the rise of
  214.    {EMACS} after about 1984.  Tends to frustrate new users no end,
  215.    as it will neither take commands while expecting input text nor
  216.    vice versa, and the default setup provides no indication of which
  217.    mode one is in (one correspondent accordingly reports that he has
  218.    often heard the editor's name pronounced /vi:l/).  Nevertheless it
  219.    is still widely used (about half the respondents in a 1991 USENET
  220.    poll preferred it), and even EMACS fans often resort to it as a
  221.    mail editor and for small editing jobs (mainly because it starts up
  222.    faster than bulky EMACS).  See {holy wars}.
  223.  
  224. videotex: n. obs. An electronic service offering people the
  225.    privilege of paying to read the weather on their television screens
  226.    instead of having somebody read it to them for free while they
  227.    brush their teeth.  The idea bombed everywhere it wasn't
  228.    government-subsidized, because by the time videotex was practical
  229.    the installed base of personal computers could hook up to
  230.    timesharing services and do the things for which videotex might
  231.    have been worthwhile better and cheaper.  Videotex planners badly
  232.    overestimated both the appeal of getting information from a
  233.    computer and the cost of local intelligence at the user's end.
  234.    Like the {gorilla arm} effect, this has been a cautionary tale
  235.    to hackers ever since.  See also {vannevar}.
  236.  
  237. virgin: adj. Unused; pristine; in a known initial state.  "Let's
  238.    bring up a virgin system and see if it crashes again."  (Esp.
  239.    useful after contracting a {virus} through {SEX}.)  Also, by
  240.    extension, buffers and the like within a program that have not yet
  241.    been used.
  242.  
  243. virtual: [via the technical term `virtual memory', prob. from the
  244.    term `virtual image' in optics] adj. 1. Common alternative to
  245.    {logical}.  2. Simulated; performing the functions of something
  246.    that isn't really there.  An imaginative child's doll may be a
  247.    virtual playmate.
  248.  
  249. virtual Friday: n. The last day before an extended weekend, if
  250.    that day is not a `real' Friday.  For example, the U.S. holiday
  251.    Thanksgiving is always on a Thursday.  The next day is often also
  252.    a holiday or taken as an extra day off, in which case Wednesday of
  253.    that week is a virtual Friday (and Thursday is a virtual Saturday,
  254.    as is Friday).  There are also `virtual Mondays' that are
  255.    actually Tuesdays, after the three-day weekends associated with many
  256.    national holidays in the U.S.
  257.  
  258. virtual reality: n. 1. Computer simulations that use 3-D graphics
  259.    and devices such as the Dataglove to allow the user to interact
  260.    with the simulation.  See {cyberspace}.  2. A form of network
  261.    interaction incorporating aspects of role-playing games,
  262.    interactive theater, improvisational comedy, and `true confessions'
  263.    magazines.  In a virtual reality forum (such as USENET's
  264.    alt.callahans newsgroup or the {MUD} experiments on Internet),
  265.    interaction between the participants is written like a shared novel
  266.    complete with scenery, `foreground characters' that may be
  267.    personae utterly unlike the people who write them, and common
  268.    `background characters' manipulable by all parties.  The one
  269.    iron law is that you may not write irreversible changes to a
  270.    character without the consent of the person who `owns' it.
  271.    Otherwise anything goes.  See {bamf}, {cyberspace}.
  272.  
  273. virus: [from the obvious analogy with biological viruses, via SF]
  274.    n. A cracker program that searches out other programs and `infects'
  275.    them by embedding a copy of itself in them, so that they become
  276.    {Trojan Horse}s.  When these programs are executed, the embedded
  277.    virus is executed too, thus propagating the `infection'.  This
  278.    normally happens invisibly to the user.  Unlike a {worm}, a
  279.    virus cannot infect other computers without assistance.  It is
  280.    propagated by vectors such as humans trading programs with their
  281.    friends (see {SEX}).  The virus may do nothing but propagate
  282.    itself and then allow the program to run normally.  Usually,
  283.    however, after propagating silently for a while, it starts doing
  284.    things like writing cute messages on the terminal or playing
  285.    strange tricks with your display (some viruses include nice
  286.    {display hack}s).  Many nasty viruses, written by particularly
  287.    perversely minded {cracker}s, do irreversible damage, like
  288.    nuking all the user's files.
  289.  
  290.    In the 1990s, viruses have become a serious problem, especially
  291.    among IBM PC and Macintosh users (the lack of security on these
  292.    machines enables viruses to spread easily, even infecting the
  293.    operating system).  The production of special anti-virus software
  294.    has become an industry, and a number of exaggerated media reports
  295.    have caused outbreaks of near hysteria among users; many
  296.    {luser}s tend to blame *everything* that doesn't work as
  297.    they had expected on virus attacks.  Accordingly, this sense of
  298.    `virus' has passed not only into techspeak but into also popular
  299.    usage (where it is often incorrectly used to denote a {worm} or
  300.    even a {Trojan horse}).  Compare {back door}; see also
  301.    {UNIX conspiracy}.
  302.  
  303. visionary: n. 1. One who hacks vision, in the sense of an
  304.    Artificial Intelligence researcher working on the problem of
  305.    getting computers to `see' things using TV cameras.  (There isn't
  306.    any problem in sending information from a TV camera to a computer.
  307.    The problem is, how can the computer be programmed to make use of
  308.    the camera information?  See {SMOP}, {AI-complete}.)  2. [IBM]
  309.    One who reads the outside literature.  At IBM, apparently, such a
  310.    penchant is viewed with awe and wonder.
  311.  
  312. VMS: /V-M-S/ n. DEC's proprietary operating system for its VAX
  313.    minicomputer; one of the seven or so environments that loom largest
  314.    in hacker folklore.  Many UNIX fans generously concede that VMS
  315.    would probably be the hacker's favorite commercial OS if UNIX
  316.    didn't exist; though true, this makes VMS fans furious.  One major
  317.    hacker gripe with VMS concerns its slowness --- thus the following
  318.    limerick:
  319.  
  320.         There once was a system called VMS
  321.         Of cycles by no means abstemious.
  322.              It's chock-full of hacks
  323.              And runs on a VAX
  324.         And makes my poor stomach all squeamious.
  325.                                          --- The Great Quux
  326.  
  327.    See also {VAX}, {{TOPS-10}}, {{TOPS-20}}, {{UNIX}}, {runic}.
  328.  
  329. voice: vt. To phone someone, as opposed to emailing them or
  330.    connecting in talk mode.  "I'm busy now; I'll voice you later."
  331.  
  332. voice-net: n. Hackish way of referring to the telephone system,
  333.    analogizing it to a digital network.  USENET {sig block}s not
  334.    uncommonly include the sender's phone next to a "Voice:" or
  335.    "Voice-Net:" header; common variants of this are "Voicenet" and
  336.    "V-Net".  Compare {paper-net}, {snail-mail}.
  337.  
  338. voodoo programming: [from George Bush's "voodoo economics"] n.
  339.    The use by guess or cookbook of an {obscure} or {hairy} system,
  340.    feature, or algorithm that one does not truly understand.  The
  341.    implication is that the technique may not work, and if it doesn't,
  342.    one will never know why.  Almost synonymous with {black magic},
  343.    except that black magic typically isn't documented and
  344.    *nobody* understands it.  Compare {magic}, {deep magic},
  345.    {heavy wizardry}, {rain dance}, {cargo cult programming},
  346.    {wave a dead chicken}.
  347.  
  348. VR: // [MUD] n. On-line abbrev for {virtual reality}, as
  349.    opposed to {RL}.
  350.  
  351. Vulcan nerve pinch: n. [from the old "Star Trek" TV series via
  352.    Commodore Amiga hackers] The keyboard combination that forces a
  353.    soft-boot or jump to ROM monitor (on machines that support such a
  354.    feature).  On many micros this is Ctrl-Alt-Del; on Suns, L1-A; on
  355.    some Macintoshes, it is <Cmd>-<Power switch>!  Also called
  356.    {three-finger salute}.  Compare {quadruple bucky}.
  357.  
  358. vulture capitalist: n. Pejorative hackerism for `venture
  359.    capitalist', deriving from the common practice of pushing contracts
  360.    that deprive inventors of control over their own innovations and
  361.    most of the money they ought to have made from them.
  362.  
  363.